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REMARKS 

Claims 1-27 were pending. E5ependent claims 28-29 are hereby added, and no 
new matter is believed to have been added thereby. Claims 1-29 are now pending. 

In the Office Action, the Examiner again rejected claims 1 , 3, 5, 11, 14-16, 18> 24, and 
26 pursuant to 35 U.S.C. § 102(e) as anticipated by Halmann, el al. (US 6,526,163). Claim 2 
was rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of Zar 
(A Scan Conversion Engine . . . ). Claims 4 and 17 were rejected pursuant to 35 U.S.C, § 103(a) 
as unpatentable over Habnann, et al. in view of Hossack, et al, (US 6,352,5 1 1). Claims 6 and 
19 were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Hahnann, et al. in view of 
Okerlund, et al. (US 6,690,371). Claims 7 and 20 were rejected pursuant to 35 U.S.C. § 103(a) 
as unpatentable over Halmann, et al. in view of Drebin, et al. (US 4,835,712). Claims 9 and 22 
were rejected pursuant to 35 U.S.C. § 103(a) as unpatentable over Halmann, et al. in view of 
Swerdloff (US 5,483,567). Claims 12, 13, and 25 were rejected pureuant to 35 U.S.C. §103(a) 
as unpatentable over Hahnann, et al. Claim 27 was rejected pursuant to 35 U.S.C. § 103(a) as 
unpatentable over Halmann^ et al. in view of Edic, et al. (US 2004/0136490). 

Claims 8, 10, 21, and 23 were objected to as being allowable if amended into 
independent form. 

Applicants respectfully request reconsideration of the rejections of claims 1-7, 9, 1 1-20, 
22, and 24-27, including independent claims 1 and 14. New arguments are provided below in 
italics. 

Independent claim 1 recites a processor operable to identify acquired ultrasound data as 
a function of the values where a look-up table has the values corresponding to a spatial 
conversion from the display format to the acquisition format. 

Halmann, et al. do not disclose this limitation. Halmann, et al. note that a CPU 
generates the scan converter tables necessary to convert scanned data from the polar cooidinate 
system to the Cartesian coordinate system where die tables are dependent on the mode of 
operation (col. 7, lines 54-59). Scan conversion is performed with interpolation and the like 
(col. 8, line 53-col. 9, line 4). Halmann, et al. do not provide further details for the tables, but 
indicate that the tables convert the data. Halmann, et al. do not use values of the table to 
identify ultrasound data where the display values are interpolated from the identified ultrasound 
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data. There is no teaching that acquired ultrasound data is identified as a function of the values 
of the look-up table. 

Claim 1 recites the table having values corresponding to a spatial conversion from the 
display format to the acquisition format Halmann, et al, convert polar coordinates into 
Cartesian coordinates (col 7, lines 55-57; and col 8, lines 64-65), not a look-up table used for 
the conversion of Cartesian coordinates to the polar coordinates. 

In reply, the Examiner cites to the creation and use of scan conversion tables (coL 7, 
lines 54-57; and coL 8, line 53'CoL 9, line 4). The Examiner alleges that, since the scan 
conversion is converting the polar scanned data to display values, it is identifying the polar 
data as a junction of the Cartesian values, and alleges that the look-up table is reversible. 

However, Halmann, et aL do not disclose the structure of the lookup table. The 
lookup table, to be used for scan conversion, likely has interpolation values given an input 
Polar coordinate. The interpolation values are then applied to the data for that Polar 
coordinate to weight the data and create Cartesian data. The table is likely for interpolation 
values for the actual conversion of data at particular coordinates, so would not have a 
Cartesian coordinate output given a polar coordinate input. The table would not be 
reversible as alleged by the Examiner, Halmann, et al. do not use values of the table to 
identify ultrasound data where the display values are interpolated from the identified 
ultrasound data. There is no teaching that acquired ultrasound data is identified as a function 
of the values of the look-up table. 

Even if reversible, Halman, et aL convert polar coordinate data to Cartesian coordinate 
data. There is no reason to identify polar coordinate data from or starting with a Cartesian 
coordinate. The process flows by providing polar coordinate data. The polar coordinate data 
is then interpolated (weighted and summed) to represent data at a Cartesian coordinate. The 
location of the Cartesian coordinate does not need to be known before hand The available 
polar coordinate data is converted An inverse lookup would not occur. 
Independent claim 14 is allowable for similar reasons as claim 1. 
Dependent claims 2-7, 9, 11-13, 15-20, 22, and 24-27 depend from claims 1 and 14. and 
are allowable for the same reasons as the corresponding base claim. Further limitations 
patentably distinguish from the cited references. 
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Claims 3 and 16 recite determining the display coordinates of interest. The Examiner 
cites to col. 8, lines 4-9 of Halmann, et al. However, col. 8, lines 4-9 show scan or polar 
coordinate data, not display coordinates. The Examiner points out that scan converted data 
are in effect display coordinates. However, Halnuinn, et al do not determine particular 
coordinates of interest, but instead just scan convert all the available polar coordinate data 
to Cartesian coordiruite data. Claim 3 also recites identifying the ultrasound data by 
inputting the display coordinates into the look-up table. The cited portions of Halmann, et al. 
do not disclose use of the table in this way. The Examiner alleges that input of coordinates 
is part of the scan conversion process. However, polar coordinate data may be scan 
converted to Cartesian coordinate data without input of the Cartesian coordinates. 

Claims 5 and 18 recite the display coordinates of interest input to the look-up table 
being coordinates for a plurality of rays through the volume. Halmann, et al. disclose a 
raycasting/volume rendering module 201, but this module 201 is not shown to work with the 
tables of the separate scan conversion module 207. 

The Examiner alleges that the coordinates of rays are examples of the input of display 
coordinates. However, Halmann, et aL, like most, treat rendering and scan conversion 
separately. Typically, scan conversion is performed for two-dimensional imaging. For 
three-dimensional rendering, the data is interpolated to a three-dimensional grid, not scan 
converted, Halmann, et al. provide no indication of deviation from this nonn, but instead 
imply use of the norm by providing independent modules for raycasting/volume rendering 
and scan conversion 

Claim 1 1 recites a graphics processing unit (GPU). A GPU is a term of art for 
hardware designed specifically for graphics processing. The CPUs of Halmann, et al. are not 
GPUs merely because they process graphics. A person of ordinary skill in the art would 
understand that a CPU is not a GPU. Given the versatile processing taught by Halmann, et 
al. (see abstract), a person of ordinary skill in the art would use a CPU» not a GPU. 

The Examiner alleges that "GPU" must be broadly interpreted as a processor that 
processes graphics since the specification does not provide a more narrow meaning. 
However, those of skill in the art would understand GPU to have a more narrow meaning. 
As a tenn of art, GPU means more than just a processor that processes graphics. As a term 
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of art, GPU is known to be more narrow. People of ordinary skill in the art would recognize 
that the processor ofHalmann, et ai is not a GPU. The Examiner cannot provide a broader 
meaning to a term of art, effectively creating his own definition contrary to accepted 
understanding. 

Claim 15 recites outputting Polar coordinates interpolated from the look-up table. 
Halmann, et al. interpolate ultrasound data, but do not disclose outputting interpolated Polar 
coordinates from the table. 

The Examiner points to the use of polar coordinates in the lookup table and that the 
coordinates are interpolated. However, this merely indicates starting with polar coordinates 
to derive display coordinates, not deriving (outputting) polar coordinates interpolated from 
the look-up table. Halmann, et aL interpolate display coordinate data from input polar 
coordinate data. 

Claim 26 recites generating a two-dimensional look-up table with acquisition format 
coordinates for each coordinate of a Cartesian volume. Halmann, et al. treat volume 
rendering separately from scan conversion. There is no disclosure of a LUT for coordinates 
of a Cartesian volume. 

The Examiner alleges that the column 7 display process would be used for a 
constructed 3D volume. However, column 5 notes that the rendering module generates an 
image (coL 5, lines 34-40). The scan conversion of column 7 is not needed and would not be 
performed since rendering and raycasting automatically determine display format data 
without the scan conversion of column 7. 

Claim 2 recites values of the look-up table being Polar coordinates where the look-up 
table is indexed by integer Cartesian coordinates. Halmann, et al. do not disclose coordinate 
values in the look-up table, and do not disclose Polar coordinates as the values of the look-up 
table indexed by Cartesian coordinates. Zar discloses bilinear interpolation of ultrasound 
data, not a look-up table of coordinates. 

The Examiner references the claim 1 discussion. As discussed for claim 7, Halmann, 
et al. do not provide these limitations. 

Claim 4 recites the processor operable to determine a plane through a volume as the 
display coordinates where the display coordinates are input to the look-up table. Hossack, et 
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al. show arbitrary plane display for a volume, but do not use the coordinates of the plane as 
an input to the look-up table. Halmann, et al. treat volume rendering and scan conversion 
separately, so do not use coordinates of a plane in a volume as input to the scan conversion 
table* Claim 17 is allowable for similar reasons. 

The Examiner references the claim 1 discussion. As discussed for claim I, Halmann, 
et al. do not provide these limitations. 

Claims 6 and 19 are allowable for the same reasons as claim 5. Claims 6 and 19 are 
also allowable because a person of ordinary skill in the ait would not have used the cited 
rendering of Okerlund, et al. with Halmann, et aL The cited section for alpha blending of 
Okerlund, et al. teach a hardware based RGBA approach (coK 7, lines 4-19). Alpha blending 
is provided using hardware acceleration. However, Halmann, et al. desire versatility so use 
progranunable CPUs to avoid hardware specialization (col. 2, lines 42-52). A person of 
ordinary skill in the art would not have used the hardware acceleration based alpha blending 
of Okerlund, et al. with the general programming approach of Halmann, et al. 

The Examiner alleges that no reason was given why the programmable CPUs of 
Halmann, et aL would not be compatible with the RGBA ofOkerlund, and notes the more 
rapid generation of images in Okerlund, However, the more rapid generation is because 
Okerlund provides a hardware based solution. The programmable CPUs would not provide 
the same speed since they are general processors, not hardware based renderers. The RGBA 
is not compatible with the CPUs of Halmann, et aL in the since that porting RGBA to 
software would not provide the advantages the Examiner relies on as a reason to even use 
Okerlund teachings with Halmann, et aL 

Claims 9 and 22 recite an additional look-up table corresponding to conversion from 
the display format to the acquisition format across multiple acquisition planes. Swerdloff 
discloses multiple tables, but not a table for conversion across multiple planes. 

The Examiner notes that a change in relationship causes another lookup table. 
However, this lookup table would be for the new plane, not across planes. 

Claim 12 recites a flag, and an integer sum. As noted in the specification, an integer 
sum allows indication of spatial relationship relative to other table entries. Halmann, et al. 
do not suggest any format for the look-up table, and certainly do not disclose an integer sum, 

- 12- 



PACE 14/15 ' RCVD AT 8/18/2008 7:24:44 PM [Eastern Daylight Time] * 8VR:U8PTO-EFXRF-6/12 « DNIS:2738300 * C8ID:650 694 5817 * DURATION (min-5s):03-22 



6506945817 sicmansmv 03:34:04 p.m. 08-18-2008 15/15 

RECEIVED 

CEMTRAL FAX CENTER 

AUG 1 8 2008 

a flag or fixed-point values. These values are chosen to allow table based identification of 
data rather than scan conversion of the data. Selective scan conversion of only the samples 
that contribute to the rendering result without having to scan convert occluded data is 
provided by the recited table variables. A person of ordinary skill in the art would not have 
provided the listed classes as a mere design choice. 

The Examiner alleges the flag and integer sum as not particularly helpful and being a 
design choice. Paragraphs 33, 38, and 50 show the specific use in the recited circumstance 
( inverse lookup). This use is not applicable to typical scan conversion, so would not be a 
design choice. 

Claims 13 and 25 are allowable for similar reasons as claim 12. Claim 13 also recites 
using the flag of the look-up table for location outside of the scanned region. Halmann, et al. 
desire to scan convert all of the data (col. 9» lines 4-13). 

The Examiner alleges that a flag when the end of the data is reached would be 
obvious. However, such as flag is used to show no more data, not used to indicate location, 
or location outside a scanned region. 

Consideration of new dependent claims 28 and 29 is requested. 



CONCLUSION 

Applicants respectfully submit that all of the pending claims are in condition for 
allowance and seeks early allowance thereof. If for any reason, the Examiner is unable to 
allow the application but believes that an interview would be helpful to tesolve any issues, he 
is respectfully requested to call Craig Summerfield at (312) 321-4726. 



PLEASE MAIL CORRESPONDENCE TO: 

Siemens Coiporation 

Customer No. 28524 

Attn: Elsa Keller, Legal Administrator 

170 Wood Avenue South 

Iselin, NJ 08830 



Respectfully submitted, 

Rosa S. Kim, Reg. No. 39.728 
Attomey(s) for App]icant(s) 
Telephone: 650-694-5330 
Date: ?-(fr'OS 
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